AWS IAM Identity Center において ABAC で EC2 インスタンスの操作を許可してみる
AWS IAM Identity Center において ABAC で EC2 インスタンスの操作を許可する設定を試してみたので紹介します。
IAM ユーザーにおいて ABAC で EC2 インスタンスを操作する場合は、IAM ユーザーに付与しているタグを利用しますが、AWS IAM Identity Center ではユーザーの属性情報を利用します。AWS IAM Identity Center が提供している Identity Center ディレクトリを利用している場合と外部 ID プロバイダーと手動プロビジョニングしている場合で試してみました。
なお、IAM ユーザーにおける ABAC や RBAC のと違いは次のブログが参考になります。
Identity Center ディレクトリの場合
AWS IAM Identity Center において ABAC を利用する場合は、設定において「アクセスコントロールの属性」を有効にする必要があります。
有効化後に、ユーザーの属性情報のなかで、どの情報を ABAC に利用するかを設定します。利用できる属性は次のユーザーガイドのページに記載があります。
AWS Managed Microsoft AD ディレクトリの属性マッピング - AWS IAM Identity Center
Identity Center ディレクトリの場合に利用できる属性を抜粋すると、次の内容です。ユーザー名やメールアドレスといった属性が利用できます。
${user:AD_GUID} ${user:email} ${user:familyName} ${user:givenName} ${user:middleName} ${user:name} ${user:preferredUsername} ${user:subject}
今回はユーザー ID を示す${user:AD_GUID}
で設定してみます。ミドルネームなどはどの属性にマッピングされているのか分かりませんでした。またの機会に確認してみたいと思います。
アクセスコントロールの属性の設定です。対応するタグ名はUserID
としました。制御のために EC2 インスタンスにUserID
がキーとなるタグを付与することになります。
設定後の画面です。
次に、下記のインラインポリシーを持つアクセス許可セットABACAccess
を作成します。ec2:DescribeInstances
の代わりに AWS 管理ポリシーの AmazonEC2ReadOnlyAccess をアタッチする、ABAC で許可する Action をec2:*
にするなどの設定もできます。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:DescribeInstances" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ec2:StartInstances", "ec2:StopInstances", "ec2:RebootInstances" ], "Resource": "*", "Condition": { "StringEquals": { "ec2:ResourceTag/UserID": "${aws:PrincipalTag/UserID}" } } } ] }
上記のアクセス許可セットを利用して EC2 インスタンスを操作したいユーザーのユーザーID をタグの値として付与します。ユーザー ID は AWS IAM Identity Center のユーザー画面で確認できます。
今回の場合は EC2 インスタンスに次のタグを付与しました。
キー | 値 |
---|---|
UserID | 07e4da48-a081-70a4-5f85-bf86df1a9106 |
試してみます。
UserID
タグの値としてアクセスしたユーザーの ID が設定されているインスタンスでは、インスタンスの停止ができました。
一方、UserID
タグの値がダミー値のインスタンスでは、インスタンスの停止はエラーとなりました。想定通りの動作です。
以上で動作確認は終わりです。
今回はユーザー ID 属性を利用しましたが、EC2 インスタンスに付与したタグの 1 つの値に対して、複数のユーザーを一致させたい場合は工夫が必要になりそうです。例えば、プロジェクト名を利用して一致させたい場合などです。ユーザー ID やメールアドレスはユーザー毎に一意な情報のため、他の ABAC 対象属性である familyName に無理やりプロジェクト名を入れるなどの工夫が必要となりそうです。
外部 ID プロバイダーと手動プロビジョニングしている場合
次に、外部 ID プロバイダーとして Microsoft Entra ID を利用しており、手動でプロビジョニングしている環境で試してみます。
ABAC の設定方法は Identity Center ディレクトリのときの同様ですが、利用できる属性情報に違いがあります。ABAC に利用できる属性情報が記載されたユーザーガイドのページを見ると対応している属性が多いことが分かります。
AWS Managed Microsoft AD ディレクトリの属性マッピング - AWS IAM Identity Center
抜粋すると次の属性情報です。部署名やコストセンターなどが利用できることが分かります。
${path:userName} ${path:name.familyName} ${path:name.givenName} ${path:displayName} ${path:nickName} ${path:emails[primary eq true].value} ${path:addresses[type eq "work"].streetAddress} ${path:addresses[type eq "work"].locality} ${path:addresses[type eq "work"].region} ${path:addresses[type eq "work"].postalCode} ${path:addresses[type eq "work"].country} ${path:addresses[type eq "work"].formatted} ${path:phoneNumbers[type eq "work"].value} ${path:userType} ${path:title} ${path:locale} ${path:timezone} ${path:enterprise.employeeNumber} ${path:enterprise.costCenter} ${path:enterprise.organization} ${path:enterprise.division} ${path:enterprise.department} ${path:enterprise.manager.value}
今回はコストセンター属性${path:enterprise.costCenter}
で試してみます。
AWS IAM Identity Center の「アクセスコントロール属性」設定は次の通りとしました。利用するタグのキー名はCostCenter
です。
ユーザーの設定においても、コストセンター属性を設定しておきます。今回はdemo
としました。
アクセス許可セットに設定するインラインポリシーは次の通りです。Identity Center ディレクトリとの違いは ABAC に利用するタグ名の指定部分だけです。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:DescribeInstances" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ec2:StartInstances", "ec2:StopInstances", "ec2:RebootInstances" ], "Resource": "*", "Condition": { "StringEquals": { "ec2:ResourceTag/CostCenter": "${aws:PrincipalTag/CostCenter}" } } } ] }
操作を許可したい対象の EC2 インスタンスには次のタグを付与しました。
キー | 値 |
---|---|
CostCenter | Demo |
試してみます。
CostCenter
タグの値として先ほどユーザーに設定したdemo
が設定されているインスタンスでは、インスタンスの停止ができました。
一方、CostCenter
タグの値がダミー値のインスタンスでは、インスタンスの停止はエラーとなりました。Identity Center ディレクトリのときと同様に想定通りの動作です。
以上で動作確認は終わりです。
外部 ID プロバイダーと連携している環境では ABAC に利用できる属性情報が多いため、Identity Center ディレクトリの場合と比べて、プロジェクト名で制御することが容易に実現できそうです。
まとめ
AWS IAM Identity Center において ABAC により EC2 インスタンスの操作を許可してみました。Identity Center ディレクトリを利用している場合と外部 ID プロバイダーと手動プロビジョニングしている場合の違いとして ABAC に利用できる属性情報に違いがあることも確認できました。
古いブログとなりますが、Microsoft Entra ID (旧 Azure AD) と自動プロビジョニングで連携している場合の ABAC は次のブログで紹介しています。AWS IAM Identity Center がまだ AWS Single Sign-On だった頃のブログです。